janvier 2004 Journées Francophones des Langages Applicatifs- JFLA04 



Typage fort et typage souple des collections 
topologiques et des transformations 



Q\ ' Julien Cohen 

o ' 
o 

(N 1 LaMI UMR 8042, 

. CNRS - Université d'Evry Val d'Essonne 

523 Place des Terrasses de l'Agora 
91025 Evry, France 

' jcohen@lami.univ-evry.fr 

(N ' 

Résumé 

0^ , Les collections topologiques permettent de considérer uniformément de nombreuses structures 

de données dans un langage de programmation et sont manipulées par des fonctions définies par 
| filtrage appelées des transformations. 

Nous présentons dans cet article deux systèmes de types pour des langages intégrant les 
collections topologiques et les transformations. Le premier est un système à typage fort à la 
Hindley/Milner qui peut être entièrement typé à la compilation. Le second est un système à 
typage mixte statique/dynamique permettant de gérer des collections hétérogènes, c'est-à-dire 
qui contiennent des valeurs de types distincts. Dans les deux cas l'inférence de types automatique 
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qq , est possible. 

1. Introduction 

Les collections topologiques sont une famille de structures de données que l'on peut voir comme 
des fonctions d'un ensemble de positions vers un ensemble de valeurs et sur lesquelles on dispose 
d'une relation de voisinage entre les positions. De nombreuses structures de données usuelles peuvent 
être vues comme des collections topologiques : ensembles, séquences, tableaux généralisés, graphes, 
etc. On peut programmer par filtrage sur ces collections grâce à des fonctions particulières appelées 
transformations. Les transformations permettent d'écrire des programmes opérant uniformément sur 
diverses structures de données. De tels programmes sont dits polytypiques JJ96 . 

Nous montrons dans cet article que les collections topologiques et les transformations peuvent 
s'intégrer dans un langage fortement typé. De plus elles y apportent des caractéristiques importantes 
comme le polytypisme et le filtrage sur des structures non- algébriques sans perdre le polymorphisme 
paramétrique ou l'inférence automatique de types. 

Dans un second temps, nous proposons un système de typage plus souple permettant de manipuler 
des collections hétérogènes, c'est à dire des collections contenant des valeurs de types différents. En 
effet, la programmation par transformations trouve un champ d'application important en simulation 
biologique où les collections manipulées sont souvent hétérogènes. Le cadre hétérogène permet aux 
transformations de gagner en expressivité par rapport au langage fortement typé. Des exemples de tels 
programmes [BT02 , BdRTGQ3] ont été codés dans le langage déclaratif MGS [Gia03j qui intègre les 
collections et les transformations dans un contexte dynamiquement typé. Les langages dynamiquement 
typés ont fait l'objet de nombreux travaux visant à leur donner un système de types proche d'un typage 
statique avec inférence de types automatique ALW94, CF91, Dam94b. Fur02J. Le langage que nous 
présentons qui permet la manipulation de collections hétérogènes est un sous-ensemble du langage 
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MGS et nous lui associons un système de types souple en partie basé sur les travaux de Aiken et 
al. |ALW94j . Ce système est doté d'une procédure de typage automatisée permettant de construire un 
type précis pour les transformations. Ce système de types est une étape importante dans l'élaboration 
d'un compilateur efficace pour le langage MGS et peut s'adapter à d'autres langages à base de règles 
de réécriture. 

La section suivante donne une intuition du fonctionnement des collections topologiques et des 
transformations et introduit leur typage. La section [3] présente notre langage fortement typé et son 
système de types. La section S] présente le langage à typage souple et énonce la correction de ce typage 
puis donne un aperçu de l'intérêt du typage pour la compilation des transformations. La dernière 
section conclut cet article en proposant des extensions directes de nos travaux et en présentant les 
travaux proches des nôtres et les perspectives ouvertes par notre travail. 



2. Collections topologiques et transformations 

Dans cette section nous introduisons les collections topologiques puis les transformations de manière 
informelle. Nous donnons également des éléments pour comprendre comment un système de types pour 
un langage fonctionnel peut les intégrer. 

Collections topologiques 

Une collection topologique est une structure de données sur laquelle il existe une relation de 
voisinage notée Vois entre les éléments. Lorsqu'on a Vois{e\,ei) on dira que est un voisin de e\. 
Par exemple, une séquence est une collection topologique telle que : 

- chaque élément possède au plus un voisin ; 

- chaque élément ne peut être le voisin que d'un élément au plus ; 

- il n'existe pas de cycle dans la relation de voisinage. 

Un ensemble ou un multi-ensemble peuvent être vus comme une collection dont tout élément est 
voisin de tous les autres éléments. 

La grille est un autre exemple de collection topologique qui est similaire à une matrice. Chaque 
élément contenu dans une grille peut avoir quatre voisins se trouvant respectivement au nord, au sud, 
à l'est et à l'ouest. Contrairement aux tableaux, la grille est une structure de données partielle. 




(a) séquence (b) ensemble (c) grille 



FiG. 1 - exemples de collections topologiques 

De nombreuses structures de données peuvent être considérées uniformément comme des collec- 
tions topologiques, aussi bien des structures usuelles comme celles que nous venons de décrire que des 
structures plus spécialisées comme les graphes de Delaunay. 

Dans le langage que nous proposons les collections peuvent être construites à partir de collections 
vides et d'opérateurs de construction. Par exemple 1 :: empty_set produit l'ensemble contenant 
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l'entier 1. L'opérateur :: peut être utilisé pour construire n'importe quelle sorte de collection^, ainsi 
on peut l'utiliser pour produire une séquence comme dans 1 :: 2 :: emptyseq. 

Quatre opérateurs sont réservés à la construction de grilles : nord, —nord, est et —est. Ceux-ci 
permettent de spécifier l'organisation entre les éléments lors de la construction de la collection. Ainsi 
on peut construire une grille carrée : 1 est 2 nord 3 —est 4 :: empty_grid ou une grille triangulaire : 
1 —nord 2 est 3 :: empty_grid par exemple. 

iii i i 

4 3 1 

12 2 3 



iii III 

Les systèmes de types que nous proposons dans cet article contiennent des types particuliers de la 
forme [r]p pour les collections où r est le type des éléments contenus dans la collection aussi appelé le 
type contenu de la collection et p est sa topologie. Une topologie peut être soit un symbole de l'ensemble 
{set, bag, seq, grid, . . .} qui représente les topologies possibles des collections, soit une variable de 
topologie que l'on pourra dénoter par la lettre grecque 9. Notons qu'une topologie n'est pas un type 
et qu'une variable de topologie ne peut être utilisée à la place d'une variable de type et vice versa. 
Les deux grilles ci-dessus par exemple ont le type [int]grid. Le constructeur nord et les trois autres 
constructeurs spécifiques aux grilles ont le type a — » [a] grid — » [a]grid où a est une variable de type. 
Le constructeur générique :: a quant à lui le type a — > [a]6 — > [a]8 car il peut être utilisé avec toute 
collection, quelle que soit sa topologie. 

On parle de collections hétérogènes lorsque les valeurs contenues dans les collections peuvent être 
de types différents. L'ensemble {f , true} contient deux valeurs de types respectifs int et bool et est 
donc un exemple de collection hétérogène. Le langage fortement typé ne permettra pas de manipuler 
des collections hétérogènes. 

Pour rendre compte de l'hétérogénéité des collections dans notre système de types souple nous 
utilisons des types unions, déjà utilisés par d'autres auteurs |AW93| |PS94| IDam94a| IFCB02] , Une 
valeur du type union t\ Ut2 est soit du type t\ soit du type Ti- Savoir qu'une valeur est du type t\ Ut2 
ne permet pas de déduire qu'elle est du type t\. L'entier 1 du type int est aussi du type int U bool. 

Nous pouvons à présent donner un type à l'ensemble {1, true}, ce type est [int U bool] set. On peut 
lire ce type de la manière suivante : « collection de topologie set qui contient des valeurs de type int 
et des valeurs de type bool » mais il est plus juste de le comprendre ainsi : « collection de topologie 
set dont les éléments ont le type int U bool ». 

L'utilisation des collections hétérogènes nécessite la possibilité de tester le type des valeurs à 
l'exécution. Ceci explique que le langage les manipulant ne puisse être entièrement typé à la compila- 
tion. 



Transformations 

Une transformation est une fonction opérant sur les collections définie par un ensemble de règles de 
réécriture de la forme m =>■ e appelées simplement règles. La partie gauche d'un règle est appelée motif 
et la partie droite expression de remplacement. On note une transformation par l'énumération de ses 
règles entre accolades : {mj => ei; . . . ; m n =>• e n }. 

1 Let sémantique de l'opérateur :: dépend de la topologie de la collection à laquelle il est appliqué. Cette forme de 
surcharge est de la même nature que la surcharge du = de ML. 
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L'application d'une transformation à une collection se fait en appliquant les règles de la 
transformation de la manière suivante : des instances disjointes du motif de la première règle sont 
recherchées puis, lorsqu'on ne peut plus trouver de nouvelle instance du motif on recherche des 
instances du motif de la seconde règle parmi les éléments qui n'ont pas déjà été filtrés, et ainsi 
de suite. Lorsque ce processus de filtrage est terminé on substitue les parties filtrées par les parties 
remplaçantes correspondantes et la nouvelle collection ainsi créée est retournée. 

Le motif x filtre une valeur quelconque ; le motif x : int filtre une valeur de type int (uniquement 
dans le langage à typage souple) ; le motif gardé x/p{x) filtre une valeur v telle que p(v) s'évalue à 
true ; le motif x, y filtre deux valeurs voisines quelconques ; enfin le motif x : int, y : int / x > y filtre 
deux valeurs entières voisines telles que la première est plus grande que la seconde. Le processus de 
filtrage a été décrit formellement dans GMC02 . 

Les transformations permettent d'exprimer simplement des programmes classiques comme le tri 
d'une séquence par exemple. Pour trier une séquence on peut chercher des couples d'éléments voisins 
mal ordonnés dans la séquence et les placer dans le bon ordre. Lorsqu'il n'existe plus de couples 
d'éléments voisins mal ordonnés la séquence est triée. Cette sorte de tri à bulles est obtenue en itérant 
l'application de la transformation suivante jusqu'à atteindre un point fixe : {x, y / 'x > y => [y, x}}. 

Dans cet exemple, l'expression [y, x] en partie droite de la règle dénote une séquence à deux 
éléments. En effet, lors du processus de filtrage, une instance du motif x, y est représentée par une 
suite de deux valeurs se trouvant en des positions voisines dans la collection. Cette suite de valeurs 
positionnées est appelée un chemin dans la collection. Ici le chemin est de longueur 2. Les valeurs 
dénotées par la séquence [y, x] viendront remplacer les valeurs du chemin filtré par la partie gauche 
de la règle. 

L'utilisation d'une séquence comme expression de remplacement convient quelle que soit la 
topologie de la collection à laquelle la transformation est appliquée. En effet, un motif filtre un chemin 
qui peut être vu comme une séquence de valeurs positionnées. Une séquence de valeurs est donc 
suffisante en partie droite pour spécifier le remplacement point à point des éléments filtrés. C'est 
pourquoi nous forçons les parties droites de règles à être des séquences. 

Dans certaines collections comme les grilles la longueur de la séquence remplaçante doit être égale 
à la longueur du chemin filtré et la substitution se fera point à point. Dans le cas contraire, la topologie 
de la collection ne serait pas préservée : une valeur ne peut être remplacée par plusieurs valeurs dans 
une grille car il faudrait pour cela insérer de nouvelles positions et la collection ne serait plus une 
grille. Ces collections dont l'ensemble de positions n'est pas modifiable sont dites newtonienne^. En 
revanche dans une séquence, un ensemble ou un multi-ensemble le chemin filtré peut être remplacé 
par un nombre arbitraire d'éléments car on peut toujours insérer une position entre deux positions 
dans ces collections. Ces collections dont l'ensemble de positions peut varier sont dites leibnitziennes. 

La fonction map qui applique une fonction à tout élément d'une collection est un autre exemple 
de programme simple à écrire : Xf.Xc.(let t = {x =>• [/ x]} in (t cj) ou de manière équivalente 
Xf.{x =>■ [/ x]\ . Ceci implémente bien un map car chaque élément e de la collection sera filtré par le 
motif x et sera remplacé par /(e). Cette fonction peut s'appliquer à toute collection, indépendamment 
de sa topologie. De telles fonctions sont dites polytypiques |JJ96j . Le polytypisme est l'un des avantages 
à considérer les structures de données dans un cadre unificateur. 

L'identité sur les collections peut s'écrire {x =4» [x]} et a le type [a]8 — > [a]8. En effet cette 
transformation s'applique à toute collection topologique et ne change ni sa topologie, ni son type 
contenu. De manière générale une transformation ne change pas la topologie de la collection à laquelle 
elle est appliquée. La transformation {x : int =>■ [x + 1]} où + est l'addition entière a également le 
type [a]9 — » [a]6 (dans le typage souple). En revanche la transformation {x [x + 1]} a le type 
[int]6 — > [int]9 dans les deux systèmes car une erreur de type aura lieu si la règle est appliquée à une 

2 Cette appellation vient de la vision différente de la notion d'espace selon Leibnitz ou Newton IGia03l . 
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valeur qui n'est pas du type int. 

Considérons à présent la transformation {x : int / (x mod 2 = 0) =>■ [true]} dans le langage 
à typage souple. Celle-ci est du type [a]6 —> [a U bool]9 mais ce type manque de précision. Il ne 
porte pas l'information que des booléens apparaissent dans la collection renvoyée uniquement si la 
collection en argument contient des entiers. Pour traduire cette information nous utiliserons des types 
conditionnels de la forme tx?t%. Le type t\?ti se lit « t\ if t-i » et vaut t\ lorsque T2 n'est pas égal 
au type nul noté et il vaudra sinon. Ainsi on peut donner le type [a]6 — > [a U (bool? (a D int))]6 
à la transformation mentionnée ci-dessus. Ce type signifie que si la collection en argument contient 
des valeurs de type int alors la collection renvoyée pourra contenir des valeurs de type bool car dans 
ce cas a n int n'est pas nul et vaut int. En revanche si le type de la collection en argument indique 
qu'elle ne contient pas de valeurs du type int alors le type de la collection renvoyée est le même que 
le type de la collection en argument. En effet dans ce cas a H int sera nul et donc bool?(a D int) sera 
également nul et a U bool? (a n int) vaudra a. 

Le typage fin des transformations avec des types conditionnels peut être vu comme de l'analyse de 
flots. On peut noter que les types conditionnels ont déjà été utilisés à cette fin (voir |FA97j ). 

3. Typage fort 

Le premier langage que nous présentons, noté C = permet de manipuler des collections homogènes et 
des transformations. Il a pour objet de montrer que les collections topologiques et les transformations 
s'intègrent bien dans un langage fortement typé comme ML. Nous présentons donc un système de 
types pour L = qui permet l'inférence automatique des types par une extension de l'algorithme de 
Damas/Milner. 

3.1. Langage C= 

Le langage C = est un A-calcul avec constantes et let auquel on ajoute les transformations, 
e : := x \ c \ Xx.e | e e | let x = e in e | {m/e => e; . . . ; m/e =>■ e; x e} 

m : := x, . . . , x 

Une transformation est composée d'une suite de règles dont la dernière dispose d'un motif qui se 
réduit à une variable. Une telle règle de la forme x =>■ e est appelée attrape-tout. Cette dernière règle 
permet de garantir que toutes les valeurs d'une collection seront filtrées par la transformation. Ainsi 
si les règles d'une transformation remplacent des entiers par des flottants par exemple on est sûr que 
tous les entiers seront remplacés et on peut garantir que la transformation préserve l'homogénéité des 
collections. 

Parmi les constantes du langage on trouve notamment des collections vides (emptyseq, empty_grid, 
. . .) et des opérateurs comme le constructeur générique de collections noté :: ou le constructeur 
spécialisé nord. 

Nous ferons un grand usage de sucre syntaxique, notamment : 

- les opérateurs binaires seront écrits en position infixe, 

- on pourra écrire une séquence en énumérant ses éléments entre crochets au lieu d'utiliser le 
constructeur standard comme le montre l'exemple suivant : [1,2,3] pour 1 :: 2 :: 3 :: emptyseq, 

- on pourra omettre la garde d'un motif lorsque celle-ci est la constante true. 

Nous ne donnons pas ici la sémantique formelle de C = . Le lecteur pourra se référer à [GM02J 
ou à GM01 pour le modèle des collections topologiques et à |Coh03aj pour la sémantique des 
transformations. Deux valeurs particulières dénotent des erreurs : wrong lorsqu'une erreur de type 
survient et shape^err lorsque l'application d'une règle viole la topologie d'une collection newtonienne. 
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3.2. Types 

Nous associons à £= un système de types à la Hindley/Milner augmenté des types collections. 
L'ensemble des topologies possibles pour une collection topologique est noté R et contient au moins 
set, seq, bag et grid. On note B l'ensemble des types de base {int, bool, float, string}. 

t ::= a | B | r -> t | [t] P p ::= 9 | R 

La lettre sera utilisée pour désigner une variable de topologie. 

Un schéma de types a est un type quantifié sur des variables de type et des variables de 
topologie de la forme Vai, . . . ,a n ,9\, . . . , 8 m .T. On dit qu'un type r est une instance d'un schéma 
de types a — Vai, . . . ,a n ,9\, . . . ,9 m .T' s'il existe une instanciation s des variables quantifiées de a 
telle que s(t') = r et on le note a < t. 

La fonction TC donne le schéma de type associé aux constantes du langage. Par exemple TC(::) 
vaut Va,6».a -> [a]9 -> [a}9. 

Un contexte de typage L est une fonction d'un ensemble de variables du langage vers l'ensemble 
des schémas de types. 



Règles de typage 

Les règles d'inférence sont celles d'Hindley/Milner augmentées d'une règle pour les transformations. 

— ■ (var — inst) ■ (const — inst) 

T \- x : t L h c : r 

r U {x : n} h e : r 2 r h ei : r' -» r P h e 2 : r' 

(/un) — (opp) 



L h (Àx.e) : ri — > T2 r h ei e2 : t 

rhei:ri r U {x : Gen(n, T)} h e 2 : r 2 
L h (Jet x = e\ in e 2 ) : r 2 



(/et) 



r, h : [r']seg h 5, : 600/ (1 < i < n) 

1 IfdTiS ) 

r I- {m-t/gi => ei; . . . ; m„/g„ =^> e„} : [r]p -> [r']p 
où Tj = T U {se// : [t]/o} U 7(m i; t) et avec 7 définie par 7((xi, . . . , x fc ), t) = {xi : r, . . . , x fc : t}. 



Comme usuellement la fonction Gen généralise un type t en schéma de type Vai, . . . ,a n ,9\, . . . ,6 m .T 
où les variables de type et de topologie quantifiées sont les variables du type qui ne sont pas liées dans 
le contexte de typage. 

Dans la règle (trans) on type toutes les règles comme si elles avaient la même forme bien que 
la dernière règle n'ait pas de garde. Ceci est naturel car le motif x est équivalent au motif x/true. 
Intuitivement la règle (trans) exprime le fait suivant : si la partie droite de chaque règle est une 
séquence de type contenu r' lorsqu'on suppose que les variables liées dans son motif ont le type r alors 
la transformation renvoie une collection de type contenu r' lorsqu'elle est appliquée à une collection de 
type t. Ceci est vrai grâce à la règle attrape-tout rendue obligatoire par la syntaxe des transformations. 
La collection renvoyée a la même topologie que la collection en argument. 

À l'intérieur d'une transformation l'identificateur self est lié à la collection à laquelle la 
transformation est appliquée. On peut remarquer que si self n'est pas utilisé dans le corps de la 
transformation celle-ci pourra toujours être polytypique. 

Si h e : r (noté aussi h e : r) alors l'évaluation de e ne provoquera pas d'erreur de type wrong. 
En revanche, l'absence d'erreur de structure newtonienne n'est pas assurée. 
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Exemple 

On peut montrer avec les règles de typage que la transformation suivante a le type [mi]0 — * [m<]0 
pour toute topologie : {x,y/x > y => [x,y, (x — y)];x => [x]} 

La preuve est donnée ci-dessous avec Ti = {x : int; y : int; self : [int]9} et T2 = {x : int; self : 
\int]6}. 

T Q (x) <int ... T 2 {x) < int 

— Tih x : int T\ h [y, (x - y)] : [int]seq L 2 h x : int 

Ti h x > y : bool T± h [x, y, (x — y)] : [int]seq T 2 \~ [x] : [int]seq 

h {x, y l 'x > y =*> [x, y, (x — y)];x =4> [x]} : [int]6 — -> [int]9 

3.3. Inférence automatique 

L'algorithme d'inférence de type automatique W de Damas/Milner s'étend simplement au langage 
C = et aux règles de typage correspondantes. Il suffit pour cela d'étendre la procédure d'unification de 
Robinson aux types collections et aux topologies ainsi que d'ajouter un cas dans W pour le typage 
des transformations. Cet algorithme est donné dans jCoh03bj et a été implémenté afin d'être intégré 
à un compilateur pour une version fortement typée du langage MGS. Comme W, il calcule le type le 
plus général d'un programme. 

4. Typage souple 

Le langage C = ne permet la manipulation des collections que dans un cadre homogène. Nous 
présentons à présent le langage Cç qui est presque identique à C = mais qui permettra des tests 
dynamiques de type afin de manipuler des collections hétérogènes. Nous associons à ce langage un 
système de types approprié qui effectue un typage statique tout en laissant certains tests de types à 
l'exécution. Ce système de types plus avancé que le premier utilise des types union et du sous-typage 
non-structurel. La procédure d'inférence automatique est plus complexe que celle basée sur W. 

4.1. Langage Cç 

Au niveau syntaxique C<z diffère de C = par la possibilité de tester dynamiquement le type d'une 
valeur durant le filtrage et la liberté d'avoir une règle attrape-tout dans la transformation ou non. 
Les tests de type sont spécifiés par annotation des variables des motifs comme le montre la syntaxe 
ci-dessous. Ces conditions de types sont restreintes aux types de base. La construction fi est appelée 
motif élémentaire et b désigne un type de base de B = {int, bool, float, string}. 

e ::= x | Ax.e | e e | c | let x = e in e | {m/e =>■ e; . . . ; m/e =>■ e} 
m ::= fi, . . . , /J, fi ::= x \ x : b 

Le langage £c s'évalue dans un domaine D qui contient les collections topologiques en plus des 
valeurs usuelles (voir [GS90] pour une introduction aux domaines sémantiques et [GM01] ou |GM02| 
pour le modèle des collections topologiques). Les transformations sont représentées dans D par des 
fonctions continue^. Leur sémantique est donnée dans |Coh03a] . D contient les valeurs spéciales wrong 
et shape^err ainsi que _L qui dénote un calcul qui ne termine pas. 

3 On peut considérer que les transformations sont déterministes en supposant que la stratégie d'application d'une 
règle est fixée mais non spécifiée. 
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À tout type de base b on associe un sous-ensemble de D — {wrong, shape^err} noté [6J et 
contenant _L. L'intersection de ces sous-ensembles deux à deux doit toujours valoir {J-}. 

Un environnement est une fonction d'un ensemble d'identifiants vers l'ensemble des valeurs D. On 
note Eval(e,E) la sémantique de l'expression e dans l'environnement E. 



4.2. Types 

La syntaxe des types est la suivante : 
t : := B | a | n — > T2 | [r]p | n U r% \ r\ fl T2 | | 1 | n?T2 

p : := iî | 

L'ensemble i? est le même que pour £ = . La sémantique des types est basée sur la notion 
d'idéal [MPS86 : un type correspond à un sous ensemble particulier du domaine des valeurs D. 
La relation de sous-typage est notée Ç et correspond à l'inclusion ensemblistc sur D. Un type ne peut 
contenir ni wrong ni shape^err. 

Voici une interprétation intuitive des types avant que nous ne donnions leur sémantique formelle. 

- Le type flèche, les types de base et les variables de type sont interprétés comme usuellement 
dans les langages fonctionnels. 

- Dans le type collection [r]p, le type contenu est r et la topologie est p comme pour C = . 

- Les types r\ U T2 et T\ PI T2 correspondent à l'union et l'intersection ensembliste des types. 

- Le type contient uniquement la valeur _L, qui représente la non-terminaison. Le type est 
inclus dans tous les autres types car _L appartient à tous les types. Le type 1 contient toutes les 
valeurs sauf wrong et shape^err. Le type 1 inclut tous les autres types. Le type — > 1 convient 
à toute fonction, y-compris aux transformations. 

- Le type conditionnel t{Iti vaut t\ lorsque T2 est différent de et il vaut sinon. Par exemple le 
type int?(r nfloat) vaut int si r contient float et sinon. 

Un schéma de type a est de la forme Vai, . . . , a n , 6\, . . . , 6 m .T where S où S est un ensemble 
de contraintes de types de la forme t± Ç T2. On utilisera par la suite le symbole x pour désigner 
indifféremment une variable de type ou une variable de topologie. On note Sol(S) l'ensemble des 
solutions de S. 



Interprétation sémantique des types 

Etant donné une instanciation s des variables de type et de topologie, la sémantique d'un type et 
d'un schéma de types sont définis dans la figure [2] par la fonction 

La sémantique d'un type de base b est l'ensemble [6J défini en section f4. Il La sémantique du type 
ti — > r 2 est l'ensemble des fonctions continues de D vers D telles que f(v) est dans [r 2 ] s (ou provoque 
une erreur différente de wrong) si v est dans [ti] s . La sémantique de tiUt 2 est l'union de la sémantique 
de T\ et de la sémantique de T2. La sémantique du type [rjp est l'ensemble des collections de D dont 
la topologie correspond à p et dont les éléments sont dans [r] s . La sémantique du schéma de types 
^Xij ■ ■ ■ ,Xn-T where S est l'ensemble des valeurs qui sont dans [t] s / pour toute instanciation s' des 
Xi solution de S (s' doit être compatible avec s sur les variables non quantifiées). 

A chaque constante c du langage on associe un schéma de types TC(c). On suppose que TC est 
correct par rapport à la sémantique : pour toute constante c du langage et pour toute instanciation s 
des variables de type et de topologie, Eval{c,%) G [TC(c)] s . 
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In - r 2 j s 
In u r 2 j s 
In n T 2 j s 



{c e Z) | s(p) est la topologie de c et Ve G ce 6 [t]«} 



[Vai, ...,On,9i,., .,9 m .r where Sj s 



où x = SoZ(S)n 



{s' k'(x) = si x £ {ai, . . . , an, 0i, . . . , 9 m }} 



FiG. 2 - Sémantique des types et des schémas de types 



4.3. Règles de typage 

La figure [3] donne notre système de règles de typage pour Cç- La relation de typage comporte un 
contexte F et un ensemble S de contraintes de types. Le jugement F, S h e : r peut se lire « dans 
le contexte de typage T, l'expression e a le type s(r) pour toute solution s de S* ». La présence d'un 
ensemble de contraintes dans la relation de typage est standard dans les systèmes de types en présence 
de sous- typage. Toutes les règles sauf (const) et (trans) sont similaires à celles de Aiken et al. 

Voici une description des règles de la figure [3] : 
(var) : Cette règle correspond à la règle standard de Hindley /Mimer, 
(const) : TG donne les schémas de types des constantes. 

(fun) et (app) : La règle (fun) correspond à celle de Hindley/Milner. Dans (app) les contraintes 
expriment qu'une fonction du type T3 — » T4 ne peut être appliquée à une valeur du type t 2 que 
si t 2 est un sous- type de T3. 

(gen) et (inst) : La règle (gen) sert à introduire le polymorphisme paramétrique dans les types. En 
effet elle exprime que si une expression a le type r sous les contraintes S alors elle a aussi le 
schéma de type V(x,).t where S où les Xi son t des variables libres de r. La règle (inst) sert à 
instancier les schémas de types en types. Pour utiliser cette règle, les contraintes du schéma de 
types doivent avoir une solution. Les Ti et pj sont libres dans cette règle. 

(let) : Le let-polymorphisme est obtenu en appliquant la règle (gen) juste après la règle (let). 

(trans) : Dans cette règle nous utilisons deux fonctions définies inductivement sur les motifs : Comp 
et 7. La première, Comp s'applique à un motif m et à un type r et renvoie un type qui vaudra 
toujours {_L} si le motif ne peut s'appliquer dans une collection de type contenu r et qui vaudra 
un type différent de {_L} sinon. On dira que cette fonction calcule la compatibilité d'un motif 
avec un type. Par exemple Comp ((x\ : int, x 2 :float), t) — (r n int) ? (r n float). Ainsi si r ne 
contient pas int et float ce type vaut {-L}. La seconde fonction, 7, calcule le contexte induit par 
un motif m sachant que ce motif est appliqué à une collection de type contenu r. 
Pour une règle rrii/gi =>■ dans (trans), r, est le type contenu de la séquence sachant que la 
transformation s'applique à une collection de type contenu r et en considérant le contexte induit 
par rrii. Le type Ti?Comp(rrii,T) vaudra {_!_} si les conditions de types de Wj font que le motif 
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n'a jamais d'instances dans une collection de type contenu r (incompatibilité), il vaudra r, si la 
règle peut s'appliquer (compatibilité). 

Le type contenu de la collection renvoyée doit être un sur- type de t{1 Compipii, r) pour chaque i, 
d'où les contraintes rp. Compim^r) Ç r' car si la règle peut s'appliquer, la collection renvoyée 
pourra contenir des éléments de type Ti. Par ailleurs lors de l'application d'une transformation 
des valeurs peuvent ne pas être filtrées et resteront dans la collection renvoyée, d'où la 
contrainte^ r Ç r'. 



ru{i: n},Sh- e : r 2 
(var) — — (jun) 



r U {x : a}, S h x : a r, S h Ax.e : ti — ► ri 

, ,s r, S\- e x : n, e 2 : r 2 
(const) — (app) 



r, S h c : TC(c) T,S U {r 2 Ç T3, ti Ç T3 — > T4} h e\ e 2 : T4 

r,She:r 



r, h e : Vxi, ■ • ■ , Xn-T where S 



{g en) si Sol(S) 7^ et Xii ■ ■ ■ 7 Xn non libres dans T 



r, S h e : Vqi, . . . , a n , 0i, . . . , 9 m .r where S' . F, 5 h ei : a Y U {a; : er}, 5 h e 2 : r _ , 

r, S U S' [ri/ ai, Pj/Oj] h e : r[r,:/ai, Pj/Oj] T, S h let x = e\ in e 2 : r 

Ti, S \- gi : bool T i: S h a : [n]seq (l<i<n) 
T, 5 U S 1 ' h {mi/gi ei; . . . ; m„/j„ =>• e„} : [r]p -> [r']p 

oîi5' = {tÇt'}U U {T i ?Comp(ro i) T)Cr'} et r, = T U {se?/ : [r]p} U 7(771,, r). 

l<i<n 

Comp (x, t) = t fi 1 = t 7(x, r) = {a; : r} 

Comp (x : b, t) = t P\b j(x : b, r) = {x : r n 6} 

Comp ((a;, m'), t) = Comp (m!,r) 7((x,m'), r) = {x : t} U 7(771', r) 

Comp ((x : b, m'), r) = (r PI b) ? Comp (m', r) 7(0^ : &j m ')i T ) — {x : t Db} U 7(771', r) 

FiG. 3 - Règles de typage 



Exemples 

Voici les preuves de typage de deux transformations simples. 



{self : [r]6; x : a fl int}, h [x; 1] : [int]seq 

0, {a Ç a, (int? (a D int)) Ç a} h {x : wi =^ [x; 1]} : [a}6 -> [a]0 

0, h {x : mr; =>■ [x; 1]} : Va, 0.[a]0 -» [a]0 where {a Ç a, (int?(a D int)) Ç a} 

Dans cet exemple l'ensemble de contraintes du schéma se réduit à 0. En effet on peut montrer que 
(int?(a n int)) Ç a est toujours vrai. Donc n'importe quelle instanciation de a et convient. 

4 On peut ne pas considérer cette contrainte lorsque l'on sait détecter que toutes les valeurs seront filtrées, afin d'avoir 
un type plus précis. Par exemple dans C— la règle attrape-tout assure que tous les éléments sont filtrés. 
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{self : [t]0;x : afl int}, 9 h [true] : [bool]seq 

0, {a Ç /3, (6ool?(a n int)) Ç (3} \- {x : int [true]} : [a]d -> [/?]fl 

0,0 h {a; : int 5 [irue]} : Va, /3, 0.[a]0 [/3]0 w/iere {a Ç /?, (booll(a n m*)) Ç /?} 

Ici le type aU(mf?(anm<)) est la plus petite instanciation de j3 vérifiant les contraintes du schéma. 
Le type suivant est donc valable pour cette transformation : [a]9 — * [a U (bool?(a H int))]9. 

Sans l'utilisation de types conditionnels, le type le plus précis pour cette transformation aurait été 
[a]6 — y [a U bool]9 qui porte moins d'informations que le type précédent. 

4.4. Propriétés 

On dira qu'un environnement E est correct par rapport à un contexte T et une instanciation s des 
variables de type et de topologie lorsque E{x) G [r(a;)] s pour tout x lié dans T et E. 

Lemme 1 (Correction) Soit un typage r, S h e : a, une solution s de 5, un environnement E correct 
par rapport à T et s portant sur les variables libres de e. Alors Eval(e, E) G [crj s U {shape_err} . 

La preuve est donnée dans |Coh03aj . Le corollaire suivant découle de ce lemme : si e est une 
expression sans variables libres et si 0,0 h e : a alors Eval{e,%) ^ wrong. Ceci est vrai car wrong 
n'appartient à aucun type. On dit qu'un programme e est bien typé si il existe un schéma de type a 
tel que 0, H e : a. Notons que le lemme ne garantit rien sur les erreurs de structure newtonicnne. 



4.5. Algorithme d'inférence automatique 

L'inférence automatique des types d'un programme consiste en deux étapes. En premier lieu, le 
schéma de type le plus général du programme est calculé en appliquant les règles de typage selon une 
stratégie appropriée. Ensuite on calcule les solutions des contraintes de types générées. Nous décrivons 
ces deux étapes dans cette section. 

4.5.1. Production du type et des contraintes 

Nous suivons la stratégie d'application des règles proposée par AW93 qui définit la dérivation la 
plus générale modulo renommage des variables de type et de topologie : 

- On utilise des variables fraîches partout où cela est possible. 

- On applique la règle (gen) immédiatement après la règle (let). 

- On applique (inst) après avoir appliqué la règle (var) ou la règle (const). 

- La dérivation se termine par une application de la règle (gen). 

- Les règles (gen) et (inst) ne sont appliquées nulle part ailleurs. 

4.5.2. Résolution des contraintes 

Une procédure de résolution de systèmes de contraintes ensemblistes est donnée dans }AW93] 
et |ALW94] . Elle est basée sur un système de réécriture qui met les contraintes sous une forme où 
leurs solutions peuvent être directement extraites. Cette procédure s'étend aux types collections en 
considérant l'équivalence suivante que l'on orientera de gauche à droite et en résolvant les égalités 
entre topologies par unification : {[ri]/Ji Ç ^J^} = {pi = P2 Ti Ç T2}. 
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La présence d'opérateurs typés dans notre langage impose également de modifier l'une des règles 
de réécriture de la procédure d'Aiken et al. : {ri — > r[ Ç T2 — > r^} se réécrit en {n Ç r'2 ; T2 Ç r'1}. 

La procédure de résolution proposée n'est correcte que sous une condition sur la forme du système 
à résoudre, laquelle est détaillée dans [Coh03aj . Nous montrons dans ce même document que notre 
procédure de production de contraintes ne produit que des systèmes solvables par notre procédure 
de résolution. On peut noter que cette condition empêche de donner d'utiliser des types intersections 
pour dénoter la surcharge d'opérateurs. Cependant nous verrons en section f5. 21 que la surcharge peut 
s'exprimer autrement dans notre système de types. 

4.6. Compilation 

En plus du gain en performances attendu lorsqu'on passe d'un langage dynamiquement typé à 
un langage statiquement typé, le typage de Ce apporte une information pouvant s'apparenter à 
de l'analyse de flot de contrôle, permettant des optimisations dans le processus d'application des 
transformations. Dans cette section, nous esquissons certaines de ces optimisations. 

Considérons la règle x : int => [x + 1] et une collection c de type contenu r. Deux cas particuliers 
peuvent se présenter : 

- Si d'après le type r la collection c ne contient pas d'entiers alors la règle ne peut s'appliquer. De 
manière générale, une règle m/g => e ne peut s'appliquer si Comp(m, r) vaut {-L}. On sait donc 
dès la compilation qu'il est inutile d'essayer d'appliquer cette règle et on peut donc la sauter 
(élimination des règles inutiles). 

- Si r = int alors on sait que les valeurs de la collection vérifieront la condition de type du motif. 
Les tests de type sont donc inutiles à l'exécution (élimination des conditions de types inutiles). 

Supposons à présent que les collections soient implémentées de manière à optimiser la recherche 
d'éléments lorsque leur type est connu. Par exemple les ensembles peuvent être implémentés par des 
sous-ensembles homogènes. Alors une optimisation est possible et elle généralise les deux premières : 
on peut chercher les instances d'un motif élémentaire dans la partie appropriée de la collection. 

Les deux premières optimisations sont simples à implémenter mais des études sont nécessaires pour 
savoir si elles s'appliquent souvent dans les programmes réels. La dernière s'applique plus souvent mais 
il peut être difficile d'implémenter les collections de manière à favoriser à la fois la recherche en fonction 
du type et en fonction de la topologie de la collection. En effet le processus de filtrage est profondément 
lié à la topologie des collections puisqu'un motif filtre des valeurs voisines. 



5. Conclusion 

5.1. Comparaison des deux approches 

Comme le montre }Wan87j . l'algorithme W de Damas/Milner est équivalent à un algorithme 
procédant par production de contraintes d'égalités entre types suivie de résolution du système 
d'équations par unification de Robinson. Par conséquent les moteurs d'inférence automatique pour C = 
et pour C<z peuvent être implémentés en suivant un même schéma production/résolution. Pour passer 
de la production de contraintes pour Ce à la production de contraintes pour C = il s'agit essentiellement 
de remplacer les inclusions par des égalités dans les règles (trans) et (app). Par ailleurs l'équivalence 
{X = Y} = {X Ç y, y C X} montre que l'on peut mêler dans un même système de contraintes des 
inclusions et des égalités. Une stratégie d'application de l'unification et de la résolution de Aiken et 
al. permet de résoudre de tels systèmes. Ces deux observations nous on conduit naturellement à 
implémenter les deux systèmes de types dans un seul moteur d'inférence automatique, en cours 
d'intégration dans un compilateur MGS expérimental. 
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5.2. Extensions 

Nous présentons ici des extensions directes de nos travaux. Certaines font déjà partie de notre 
implémentation du système alors que d'autres sont des voies pour des travaux futurs. 

Constructions usuelles. Les constructions usuelles telles que le produit ou le let-rec n'ont pas été 
considérées pour ne pas alourdir la présentation mais leur ajout au langage et au typage se fait 
de manière habituelle et ils sont présents dans notre implémentation. 

Gardes dans le motif. Pour la simplicité de la présentation nous avons restreint l'usage de la garde 
dans un motif mais on peut étendre aisément le langage des motifs afin d'avoir une garde associée 
à chaque motif élémentaire, comme fait dans Coh03b] et garder les propriétés du typage fort ou 
du typage souple. Mettre des gardes au plus tôt dans le motif permet d'optimiser le processus de 
filtrage. Par exemple le filtrage du motif (x/x>0),y est plus rapide que pour x,y/x>0. Cette 
extension fait partie de notre implémentation. 

Des types plus précis. Nous avons vu que le système de types de Ce permettait d'inférer des 
types assez précis. Pourtant dans au moins deux cas que nous montrons ici des types plus précis 
existent. 

Le type inféré pour la transformation {x : int =>• [irue]} est [a]6 — > [a U (bool7(a n int))]6. Ce 
type ne porte pas l'information que la collection renvoyée ne contient plus d'entiers. 
- Le type inféré pour la transformation {x : int [x];x : int =>• [irwe]} est [a]6 — > 
[a U (booP.(a H int))]6. Or la deuxième règle ne s'applique jamais car tous les entiers sont 
consommés par la première donc le type [a]6 — + [a]9 qui est plus précis convient. 
La règle (trans) de Ce analyse sommairement les conditions dans lesquelles les règles peuvent 
s'appliquer (par le biais des types conditionnels et de la fonction Comp). Les deux exemples 
ci-dessus montrent que l'analyse des motifs et des transformations doit être plus subtile pour 
inférer le type le plus précis d'un programme. Par exemple l'amélioration proposée dans la note 
de bas de page numéro 2] permet d'obtenir le typage le plus précis pour la fonction map qui est 
(a -y P) -> [a]9 -> [f3]9 au lieu de (a -> f3) [a}0 — > [a U (3}9. 

Étoile dans un motif. Les motifs tels que nous les avons présentés permettent uniquement de filtrer 
des parties de taille prédéterminée. Il existe toutefois des cas où le programmeur aimerait filtrer 
des parties de la collection de taille arbitraire, comme montré dans [GMC02]. Afin de permettre 
ceci, nous introduisons une nouvelle construction dans les motifs appelée Y étoile et notée * qui 
exprime le filtrage d'un nombre d'éléments arbitraire. La grammaire des motifs élémentaires est 
modifiée comme suit : 

/i ::= x | x : b | * as x \ b* as x 

Dans le motif élémentaire * as x, l'identificateur x dénote la séquence des valeurs filtrées par 
l'étoile et peut être utilisé dans la garde du motif et dans l'expression de remplacement de la 
règle. Le fait que x dénote une séquence plutôt qu'une partie de la collection est en accord avec 
la contrainte d'avoir une séquence comme expression de remplacement. 

Le typage de ces nouveaux motifs nécessite uniquement la modification des fonctions 7 et Comp 

de la manière suivante : 

7(* as X,t) — {x : [r]seq} Comp(* as x,t) =1 

7(6* as x,t) = {x : [r H b]seq} Comp(b* as x,t) =THi) 

Les répétitions arbitraires sont intégrées à notre implémentation. 

Direction à la place de la virgule dans un motif. Dans une structure de données comme la 
grille, on peut vouloir filtrer des éléments voisins selon une direction donnée. Ceci peut ce faire 
simplement comme dans le motif suivant : x,y/(nord-nb self x y) où nordjnb est la relation 
de voisinage correspondant au constructeur nord. Toutefois il est avantageux de placer cette 
information de voisinage au niveau syntaxique afin de l'utiliser efficacement durant le filtrage. 
Ainsi dans le langage MGS on écrit directement x \nord> y. La virgule a été remplacée par le 
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constructeur nord encadré des symboles | et >. Cette nouvelle construction dans le langage ne 
nécessite pas de modification dans le typage puisqu'elle peut être vue comme du sucre syntaxique. 

Lisibilité des types. Un schéma de types de £ç contient un ensemble de contraintes qui peuvent 
se révéler obscures pour le programmeur. F. Pottier a formalisé une notion de simplification de 
systèmes de contraintes dans |Pot98j dans le but de rendre les schémas de types plus lisibles 
par le programmeur. Une telle simplification nous semble essentielle dans un but d'aide au 
développement . 

Surcharge. Comme le font remarquer Pantel et Sallé dans [PS94] les types conditionnels introduits 
par Aiken et al. peuvent servir à dénoter la surcharge de la manière suivante. Si {Ui — > V{\ est 
l'ensemble des types d'une fonction surchargée alors on peut lui donner le type suivant dans 
notre système : 

Va.a -> \J(Vi?a n U % ) where {a Ç (J Ui} 

i i 

Exemple. On peut donner le type suivant à l'addition sur les entiers et les flottants : 
Va. a — > a — ► (intla n int) U (floatla D float) where {a Ç int U float} 

Types récursifs. Les types récursifs ne sont pas intégrés directement à la grammaire des types mais 
on peut définir des types récursifs à l'aide de contraintes de la manière suivante : le schéma de 
types \la\a\bag where {a — [a]bagUint} dénote les multi-ensembles pouvant contenir des entiers 
et des multi-ensembles contenant à leur tour des entiers et des multi-ensembles et ainsi de suite. 
Dans cet exemple on a utilisé l'égalité entre types définie par {t± = T2} = {t\ Ç T2,T2 Ç t±}. 

5.3. Discussions 

Erreurs de structure newtonienne. La faiblesse de nos systèmes de types est qu'ils ne 
permettent pas de détecter les violations de structures newtoniennes à la compilation. Pour le faire il 
faudrait garantir que le chemin filtré et la séquence remplaçante ont la même taille. Or ceci n'est pas 
toujours possible car : 

- la taille de la séquence remplaçante ne peut pas toujours être calculée à la compilation ; 

- la taille du motif n'est pas connue à la compilation si une répétition arbitraire * y est utilisée. 
Toutefois il existe des cas où l'on peut détecter que shape_err sera renvoyé ou ne sera pas renvoyé. 

Déterminer l'ensemble des programmes pour lesquels l'apparition d'une shape^err est décidable est 
souhaitable mais notre système de types est mal adapté à ceci. Il existe également des systèmes de 
types prévus pour l'inférence automatique de tailles |Gia92[ ICK01] . 

Types sommes ou types unions ? Les types unions et les tests de type à l'exécution peuvent 
sembler superflus lorsque l'on sait que les types sommes avec constructeurs permettent de programmer 
de manière similaire dans un contexte statiquement typé. Les collections hétérogènes et les types unions 
sont bien plus flexibles que les types sommes mais permettent moins de vérifications automatiques, 
lesquelles sont essentielles à la construction de logiciels sûrs. Par exemple ils ne permettent pas de 
vérifier l'exhaustivité du filtrage, contrairement aux type sommes (voir [Mar03 J. 

Toutefois, dans certains domaines d'application, la complexité des processus modélisés est telle 
que les types sommes deviennent trop lourds. D'autres auteurs partagent cette idée. Par exemple 
J. Garrigue étend les types sommes aux types sommes polymorphes dont les types ne sont pas 
nécessairement déclarés et dont les constructeurs peuvent être utilisés dans différents types |Gar98j . 
Il les utilise intensivement pour interfacer des bibliothèques C (comme OpenGL ou GTK) au langage 
O'CAML. Les types sommes polymorphes apparaissent dans la version 3 de O'CAML [LDGV02J. Par 
ailleurs A. Frisch et al. utilisent des types unions pour typer le langage CDUCE dédié à la manipulation 
de données XML [FCB02) . Il existe d'autres exemples où la manipulation de données venant de 
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l'extérieur nécessite un langage supportant l'hétérogénéité mais nous sommes particulièrement motivés 
par des programmes issus de la biologie tels que la simulation de cellules. Dans ce type de simulation 
on doit gérer des entités qui migrent entre compartiments et des réactions pouvant avoir lieu sans 
que l'ensemble des entités pouvant être rencontrées ne soit connu a priori. La définition d'un type 
somme pour représenter l'ensemble des entités possibles est très lourde dans ce cas. Les collections 
hétérogènes sont ici une solution appropriée. De telles simulations ont été programmées à l'aide du 
langage MGS (voir |BT02j ). 

On peut également noter que l'approche orientée objet se prête à l'implémentation de collections 
hétérogènes. Toutefois, que ce soit avec des Vector en JAVA ou des listes en O'CAML l'utilisateur est 
obligé à un moment ou à un autre de coercer explicitement les éléments des collections. Par ailleurs 
cette approche contraint à considérer toujours des objets alors que bien souvent des types de base 
suffisent. Enfin, la définition d'opérations polytypiques par le programmeur reste assez lourde dans ce 
cadre. 



5.4. Travaux apparentés et perspectives 

Les travaux de Aiken et al. AW93, ALW94] fournissent une méthode d'inférence de types en 
présence de types unions qui sert de base à notre système de types souple, en effet les types union 
sont la clé de notre représentation de l'hétérogénéité. Le filtrage apparaissant dans [ALW94] est en 
revanche prévu pour des termes et n'est pas adapté à notre filtrage. Toutefois les types conditionnels 
apparaissent déjà dans ces travaux pour exprimer une analyse de flots lors du filtrage. Notre travail 
se démarque fortement du leur par le point de vue original sur le typage des structures de données et 
la puissance du processus de filtrage que nous typons. 

Les travaux de A. Frisch et al. [FCB02] sont assez proches des nôtres puisqu'ils proposent un 
système de types basé sur un modèle ensembliste pour un langage avec filtrage sur le type des valeurs 
où l'hétérogénéité des données est représentée par des types unions. Toutefois la puissance de leurs 
motifs les contraint à imposer une déclaration du type des fonctions dans [FCB02 . 

D'autres systèmes de types existent pour des langages à base de règles. Par exemple les travaux de 
P. Fradet et al. [FLM98] munissent le langage Gamma d'un système de types dédié à la vérification 
de propriétés des programmes. En effet Gamma est à l'origine un langage dédié à la spécification 
formelle de haut niveau. Dans une optique d'implémentation efficace de Cç notre système semble 
plus approprié. Le système de types de Gamma permet en revanche d'envisager des vérifications de 
préservations de topologie (sans résoudre les difficultés discutées en section |5TÏÏ|) . 

Nous avons utilisé nos deux systèmes de types dans un compilateur MGS pour éliminer l'étiquetage 
des valeurs par leur type lorsque possible. Ceci permet de grandes améliorations des performances, ce 
qui nous incite à intégrer d'autres optimisations basées sur les types telles que l'élimination des règles 
inutiles (voir section |4~6|) . D'autres langages à base de règles de réécriture pourraient tirer bénéfice de 
ces systèmes de types. 

De nombreux travaux s'attellent à rendre le filtrage plus expressif. Citons TOM MRV03] un 
compilateur de filtrage adapté à plusieurs langages (C, JAVA, Eiffel) et permettant le filtrage 
associatif; ELAN [MK98] . un langage fondé sur la réécriture et proposant une implémentation très 
efficace du filtrage associatif et commutatif ; enfin CDUCE [FCB02] et G'CAML [Fur 02] qui permettent 
de filtrer les valeurs en fonction de leur type. Les langages C = et Ce qui sont des sous-ensembles 
du langage MGS proposent du filtrage associatif, commutatif, sur des structures non algébriques et 
également sur le type des valeurs dans le cas de Ce ■ 

Enfin, notre expérience de la programmation en MGS montre que les enregistrements 
extensibles IRém93j sont particulièrement utiles et adaptés à une utilisation dans un cadre hétérogène 
(voir de nombreux exemples de programmes dans [Gfxj ) . Nous souhaitons ajouter les enregistrements 
à nos systèmes de types et permettre les tests de types d'enregistrements lors du filtrage. Nous 
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pensons également étudier comment augmenter les tests de types dans le filtrage sans perdre l'inférence 
automatique. 
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